The rapid growth of the complexity of modern electronic circuits has forced electronic circuit designers to rely upon computer programs to assist or automate most steps of the design process. Typical circuits today contain hundreds of thousands or millions of individual pieces or “cells.” Such a design is much too large for a circuit designer or even an engineering team of designers to manage effectively manually.
An electronic design automation (EDA) system is a computer software system used for designing integrated circuit (IC) devices. The EDA system typically receives one or more high level behavioral descriptions of an IC device (e.g., in HDL languages like VHDL, Verilog, etc.) and translates this high level design language description into netlists of various levels of abstraction. A netlist describes an IC design and is composed of nodes (elements) and edges, e.g., connections between nodes, and can be represented using a directed cyclic graph structure having nodes which are connected to each other with signal lines. At a higher level of abstraction, a generic netlist is typically produced based on technology independent primitives. The generic netlist can be translated into a lower level technology-specific netlist based on a technology-specific library that has gate-specific models for timing and power estimation. A single node can have multiple inputs and can output a signal or signals to multiple other nodes. The netlist is typically stored in computer readable media within the EDA system and processed and verified using many well-known techniques.
The design flow for the design of integrated circuits (e.g., ASIC, microprocessors, microcontrollers, etc.) requires several descriptions of the design library that are used as input to different CAD tools. For instance, a synthesis library is typically required. The main loop in the IC design environment consists of describing the IC design in terms of primitive models from the synthesis library, verifying (e.g., functionality, power and timing constraints, etc.) through various verification techniques and then refining and correcting the IC design. During this process, timing and power estimations or analyses are often performed by the computer system to optimize the IC design and to determine if the overall circuit design is maintaining prescribed timing and power constraints.
In the conventional art, a list of exceptions is typically an input to an EDA tool, for example a timing analysis tool. The exceptions are non-default constraints, e.g., timing constraints that delineate exceptional circumstances that are generally not addressed by the default behavior of the EDA tool. For example, conventional EDA timing analysis tools can not determine if a synchronous path is intended to function in one clock cycle (a typical default for the EDA tool) or if that path is designed to function in multiple clock cycles. Typically an exception specifies such a multi-cycle path. There are numerous other reasons for, and types of, exceptions. These are generally well known by those of ordinary skill in the EDA arts. A widely used design constraints format, known as Synopsys Design Constraints (SDC), commercially available from Synopsys, Inc. of Mountain View, Calif., describes the “design intent” and surrounding constraints for synthesis, clocking, timing, power, test, environmental and operating conditions and the like for various EDA tools from multiple vendors.
FIG. 1 illustrates an exemplary portion 100 of an integrated circuit design. Symbols A 110, C 112 and D 114 designate input terminals to circuit portion 100. Symbols E 116 and F 118 designate output terminals of circuit portion 100. Logic bates 101, 111, 120, 130 and 140 are also denoted by “u” or “module” numbers as is conventional in the electronic arts. For example, u0, u1, u2, u3 and u4 correspond to drawing designators 101, 111, 120, 130 and 140 respectively. Several nodes within circuit portion 100 are further identified. Inputs to u3130 are designated u3/i0132 and u3/i1134. Similarly, the output of U2120 is designated u2/o. The input to U4140 is designated u4/i 142.
An exemplary exception may be applied to circuit portion 100 as follows:                set_false_path-from A-to FThis exception instructs an EDA tool, e.g., a timing analysis tool, to ignore timing characteristics from A 110 to F 118.        
Modern integrated circuit designs may comprise hundreds of thousands to millions of gates. The number of interconnections between such gates may be an order of magnitude greater than the number of gates. The number of signal paths among such gates, e.g., from a first input through a number of gated to an output, may be several orders of magnitude higher still. Typically, the vast majority of such permutations of possible signal paths are not part of a desired signal flow of the circuit. As an unfortunate consequence of the tremendous numbers of such paths, it is impractical for human designers to study each possible signal path and manually specify an exception if necessary.
Numerous tools and techniques have been employed to facilitate the generation of exceptions. Among such techniques are the wide use of “wildcards” to specify entire sets of nodes, e.g., u3/i* to specify all inputs to u3, the use of historical exception lists from predecessor designs, automated scripts and automatic exception generators. For example, it is not uncommon to generate one million exceptions by such means. Unfortunately, due to mistakes, oversights, tool defects and the like, typically many exceptions which are specified are invalid or specified in a non-optimal form. Conventional EDA tools suffer, for example, increased execution time and increased memory requirements as a result of analyzing such non-optimal exceptions.
Further, as circuit designers become more detached from the generation of exceptions, outputs from EDA tools, e.g., a timing analysis tool, become more difficult to understand and interpret. For example, it may be difficult to determine that a critical path was erroneously listed as an exception, and consequently no analysis was performed on that path. Therefore, a method for optimizing exceptions is much needed and highly desirable.